home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.sys.amiga.misc
- Path: cix.compulink.co.uk!usenet
- From: jralph@cix.compulink.co.uk ("Jolyon Ralph")
- Subject: Re: What I want from new Workbench
- Message-ID: <Do0B57.K5J@cix.compulink.co.uk>
- Organization: Compulink Information eXchange
- References: <4hpkbm$vei@serra.unipi.it>
- Date: Sat, 9 Mar 1996 15:31:55 GMT
- X-News-Software: Ameol32
-
- > : Rewrite MUI in assembly? Ugh!!! Besides, I doubt it will improve the
- > speed
- > : very much. CPUs and Graphics cards get faster all the time.
- > YEs it would... v3.2 or v3.3 is significantly faster than previous ones
- > also because small portions were rewritten in assembly.
-
- The big problem with MUI (and most other GUI systems, for that matter) is
- that it doesn't fit well into the Amiga multitasking model (or at least
- it didn't last time I looked at it).
-
- MUI appears 'slow' not because it's running on a slow CPU, not because
- the code isn't optimised or written in assembler.
-
- It's slow because they leave handling window refresh up to the
- application. Whenever your code is busy, the window is busy and gadgets
- do not respond.
-
- A true GUI system should multitask with your own code. Each requester
- should have its own task controlling the GUI elements. If you move a
- slider, the slider, and any other objects linked to it, update
- immediately. It shoudn't wait until your code has caught up with it.
- Don't believe the BS that many MUI fanatics have been posting, pretty
- customisable scalable GUI's don't HAVE to be slow. We know, we've done
- it. Our system runs at high speed even on a standard A1200. (Perhaps one
- day we'll release a developer version of our system, but it was developed
- primarily for in-house use, and it's not finished yet...).
-
- Porting MUI to asm, to PowerPC, running on a gfxcard will make very
- little difference without a total redesign of the way MUI works.
-
- Jolyon
-
-